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This set of documentation mainly provides the software program designs that make up the code base and 
planned enhancements and additions. In EA terms, it’s probably most like a “Software Design Document 
(SDD),” but we often refer to it as the TDD or TDR. 


It should serve as the basis of a final TDR after the written game design is complete. 


1. Goals and Audience 


1. People added to the project can learn everything they need to know in order to produce. 


2. The document serves as a vehicle for identifying, ironing out, and reviewing the remaining technical 
design issues 


3. It serves as the basis for defining and estimating development tasks. 
4. It codifies the engineering philosophy and standard for robustness. 


5. It identifies game design and technical unknowns, and supports the creation of plans and experiments 
to resolve them. 


2. Intermediate and Final States 


In the previous months of experimental and production programming, we have accumulated a lot of 
running software, and design ideas going forward. To support a growing team, and to solidify our mutual 
understanding and overall design quality, we did a substantial round of technical documentation leading up 
to mid-October 1997, in advance of writing a detailed game design script. Most major areas were 
documented to a state we call “Intermediate Stage” or “Alpha State.” 


The goals above can be refined to set the standard for this stage of the documentation: 


1. Design of current software subsystems is complete and detailed enough for any member of the 
technical staff to read, interface, or make minor modifications. Suitable for bringing a new team 
member rapidly up to speed. 


2. Designs reviewed by the team for clarity, validity, and efficiency. 


3. Designs for programming yet to come meet the same standards of clarity and detail, but may be 
incomplete due to items “to be determined” in the game design, or by virtue of performance 
experiments or proofs-of-concept that need to be planned and executed. 


4. Game design “TBD’s” are phrased in the form of a question that can be answered in the written game 
design. 
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